Skip to content

libc: use more accurate type of sighandler_t on windows #4602

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

mbyx
Copy link
Contributor

@mbyx mbyx commented Jul 31, 2025

Description

Changes the type of sighandler_t on windows from usize to *const c_void as per #1637 to more accurately represent the fact that it is a pointer to a function (since the value of the address is also sometimes matched without dereferencing it).

A better type would be Option<extern fn ...> however because of the dual use of sighandler_t as a constant, it would be undefined behavior to construct that type from something like 5.

Sources

https://github.com/msys2/msys2-runtime/blob/23a25d49e3b8c18f12ce588869d4cb24de9f2454/newlib/libc/machine/cris/sys/signal.h#L23

Checklist

  • Relevant tests in libc-test/semver have been updated
  • No placeholder or unstable values like *LAST or *MAX are
    included (see #3131)
  • Tested locally (cd libc-test && cargo test --target mytarget);
    especially relevant for platforms that may not be checked in CI

@@ -10,7 +10,7 @@ pub type ptrdiff_t = isize;
pub type intptr_t = isize;
pub type uintptr_t = usize;
pub type ssize_t = isize;
pub type sighandler_t = usize;
pub type sighandler_t = *const c_void;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One concern: if Rust ever does get raw function pointers, it would be a breaking change to start using them. So I'm thinking maybe we should create an opaque type that would let us change to a raw function pointer at some point, ideally something compatible with rust-lang/libs-team#589 (comment).

Will need to think about this a bit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants